1. Technical Field
The present invention relates generally to an improved data processing system and, in particular, to a process and system for improving object interaction in an object-oriented environment. Specifically, the present invention relates to a process and system for improving name service behavior in an object-oriented programming environment.
2. Description of Related Art
Today""s world of networking involves both Intranets for localized access and Internets for global access. Naming and directory services are vitally important for finding and/or accessing persons, machines, networks, services, and applications. Any naming service should be able to characterize the arrangement of objects and identification of specific entities in a human understandable format.
A namespace typically involves the composite of several different naming facilities. URLs (Universal Resource Locators) are a good example of a composite name space. At the top level, the Internet Domain Name Service (DNS) may be used. Name services within an organization vary from location to location. Some examples are LDAP (Lightweight Directory Access Protocol) or NDS (Novell Directory Services) or NIS (Network Information System). However, from a user perspective, this composition of different namespaces should be transparent.
The Java Naming and Directory Interface (JNDI) is a set of software tools from Sun Microsystems, Inc. that provides directory and naming functionality for Java applications. The JNDI architecture consists of an API (Application Programming Interface) and an SPI (Service Provider Interface). To find an object in the namespace, a context object is retrieved which represents the root of the namespace. The retrieved context object is then used to lookup an object in the namespace by supplying a path from that context to the object""s location in the namespace.
Scoping of names occurs in many domains of computer science. For example, two different functions in an application program, Function 1 and Function 2, may each use local variables named xe2x80x9cixe2x80x9d and xe2x80x9cjxe2x80x9d to control access to a two-dimensional array. Although the same names are used for similar variables within the namespace of the application program, there is no conflict between the variable names due to the scoping of the variable names within the partitions of Function 1 and Function 2. The xe2x80x9cixe2x80x9d and xe2x80x9cjxe2x80x9d inside of the block of code named Function 1 is not visible from inside of the block of code named Function 2, and similarly, the xe2x80x9cixe2x80x9d and xe2x80x9cjxe2x80x9d within Function 2 is not visible within Function 1. This limiting of the scope of names is extremely useful because a programmer does not have to be concerned whether a variable name that has been chosen for an object happens to be used elsewhere in the same program.
Namespace scoping works very similarly to scoping of variables in programming. It works by using arbitrary partitioning of the namespace tree (a hierarchy of locations arranged in a tree) into branches which represents scopes. Accessing an object in the namespace under a particular scope can be performed by fully specifying the path from the root of the namespace tree to that object including the scoping branch of the tree. This is an explicit form of scoping. However, implicit scoping implies being able to use a path which is not fully specified, yet still navigate the namespace tree from the root using a particularly scoped branch of that tree to lookup an object.
JNDI does not specify any scoping behavior for a name service. As an example, consider an Enterprise JavaBean (EJB) application that is composed of many EJBs that must use a naming system to resolve references to each other. In other words, the names must be clearly distinguishable to avoid conflicts and collisions. Enterprise JavaBeans objects (EJBs) usually handle references to other EJBs by defining property settings in the EJB environment data. These property settings typically define the fully qualified namespace path as well as the context object used to access other EJBs. This is because the namespace name and server host/port registered for the EJB cannot be predicted by the developer of the EJB. Since this data is defined as part of the deployment data of an EJB at deployment time, it requires redeployment and recompilation if it is to be changed. An explicit form of namespace scoping could be used. However, changing the deployment data for a particular scope and redeploying can be very time consuming, possibly taking hours for large systems. This process is also very error prone since the data must be changed manually in multiple places (at least once for each EJB) and must be consistent throughout the entire application. In other words, if an EJB is to be used under a new scope, it must be bound (registered) in the namespace under the new scope and all references to it must be changed to use the new scope. This becomes increasingly difficult as the number of EJBs and their relationships increase.
Therefore, it would be advantageous to have a mechanism to provide implicit name scoping behavior, and it would be especially advantageous to have a mechanism for name scoping behavior within JNDI.
The present invention implements a process and system for providing name service scoping behavior. In an object-oriented data processing system, a request is received for an initial context for a namespace from a requesting object. A scoped initial context factory object is constructed, and an initial context is requested from the scoped initial context factory object. A class for the scoped initial context factory object may be determined from a variable in a hash table object passed as an argument. In response to the request for an initial context from the scoped initial context factory object, an initial context is requested from a non-scoped initial context factory object. The scoped initial context factory object may be a subclass of the non-scoped initial context factory object. The initial context returned by the non-scoped initial context factory object is scoped to a partition of the namespace, and the scoped initial context is returned. The initial context returned by the non-scoped initial context factory object may be scoped by performing a name service lookup on the partition of the namespace. The requesting object and the scoping object may be implemented in a platform-independent object-oriented programming language, such as Java.